SPF, DKIM and DMARC records

SPF

The SPF record is created as a DNS “TXT” record within the root of your DNS zone. If you’re using Exchange Online, Microsoft provides a starting point of the value for your SPF but it will likely need to be customized. The default value listed in your tenant will be:

v=spf1 include:spf.protection.outlook.com -all

This value will work if you’re only sending messages out of Exchange Online and have no on-premises infrastructure relaying messages. If you have other systems sending mail, you’ll want to make sure that you include these sources in your SPF record. Common issues I see with SPF records are organizations that try to add more than one TXT record, add too many (>10) DNS queries within their SPF record or just have an improper syntax. There are a number of sites that can validate your SPF record including MxToolbox.

DKIM

Configuring DKIM signing in Exchange Online is relatively simple. You essentially need to create two DNS records and run three PowerShell commands for each of your SMTP domains. First we need to determine the appropriate values for the DNS records. In the tenant, run the following command for each of your SMTP domains:

New-DkimSigningConfig -DomainName company.com -Enabled $False

Then run the following to get the values:

Get-DkimSigningConfig company.com | FL Domain, *CNAME

Now it’s time to create the two DNS records. You’ll create the following two CNAMEs using the output from the above command:

Host: selector1._domainkeyPoints To: selector1-company-com._domainkey.company.onmicrosoft.comHost: selector2._domainkeyPoints To: selector2-company-com._domainkey.company.onmicrosoft.com

Once the DNS records have propagated, return to PowerShell and run:

Set-DkimSigningConfig company.com -Enabled $True

You’ll soon start to see that your messages now show as DKIM signed in the message headers.

DMARC

Once you have SPF and DKIM properly configured, you may choose to start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports. You’ll likely want to start with an action of “none” meaning that you just want to monitor emails not but take any action. Even if you can’t get to the point where you configure an action of “quarantine” or “reject”, you can still use DMARC to help mitigate phishing attempts. After determining the action type, you will probably want to use a third-party service to help analyze the DMARC reports. Your published DMARC record will tell recipients that support DMARC to email reports to the address specified in the DNS record. These reports will arrive as a compressed attachment containing an XML file. There are a number of services that can assist with analyzing DMARC reports, some that are free, some that are paid and many that have 30-day trials. For my low-volume testing, I used “dmarcian” but there are a number of others listed at “dmarc.org“. These services will usually provide you two email addresses to publish: one for the aggregate reports and one for failure reports. Now it’s time to publish your DMARC record. This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC. A typical DMARC record might look this this:

Host: _dmarcTXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"

Again, you should use one of the validation sites like “MxToolbox” to check your published DMARC record. You will now start seeing reporting data appear in your DMARC analyzer service from recipient organizations that support DMARC. The data presented will vary depending your service but you should have the ability to see which emails are passing DMARC and which emails are failing.